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(57) Abstract: The present invention relates to a portal 
structure providing end user stations (5) with access 
to services/applications (26), comprising a portal core 
(1) and a number of services/applications (26). The 
portal core comprises a presentation arrangement, 
portal session managing means (13) generating session 
related information, e.g. session identifications and 
portal storing means (51) for storing session related 
information. At least some of the services/applications 
(26) are external with external session identifications. 
Session unifying means (50) are provided for mapping 
between portal session identifications and external 
session identifications. For communication between the 
portal core (1) and external services/applications (26), the 
external identification is used, whereas, in communication 
between an end user station (5) and the portal core (1), 
only the portal session identification is used. 
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Title: 

AN ARRANGEMENT AND A METHOD RELATING TO SESSION MANAGEMENT 
IN A PORTAL STRUCTURE 



TECHNICAL FIELD 

The present invention relates to session management and portal 
structures, particularly Internet portals, providing end user 
stations with access to services/applications. The invention 
also relates to an arrangement in a portal structure used for 
session management. The invention further relates to a method of 
session management in a portal structure for end users accessing 
services/applications via said portal structure. 



The invention particularly relates to handling of session 
management when different entities, such as portals, services or 
application are managed by different session management means. 

STATE OF THE ART 

When referring to a portal is generally meant an Internet 
portal. Internet portals interacting with end users usually 
provide for session management in order to be able to track and 
keep control of the activities of the end users, and in order to 
store end user specific information, like authentication status, 
information, such as lists and order of initiated actions and 
resulting events etc. Today a portal often needs to be able to 
integrate functionality of other software systems or even other 
portals. However, sometimes such other systems, such as 
services/applications or other portals, have their own session 
management. This means that in one way or another session 
management as provided for by different session managing means 
needs to be integrated or combined. 
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There is also an increasing need to personalize or customize the 
way an end user can access services irrespectively of the actual 
location of the services or applications, or who' is the 
provider. Also the demand for access to mobile Internet services 
gains importance, i.e. that end users may want to be able to, in 
a rapid and uncomplicated manner, get access to services from 
any end user station, i.e. also from mobile devices; it may e.g. 
relate to sending and receiving e-mails, short messages, 
accessing web-based information from mobile as well as from 
fixed end user devices in a user-friendly, quick and simple 
manner. This is called the mobile Internet. 



Browsing using a mobile device is however more difficult than 
browsing using a PC, since the mobile device, as compared to the 
PC, has limited input and output capabilities. Thus, this means 
that it gets even more difficult to provide mobile end users 
with a satisfactory personalization, and management of services 
as well as session management get even more complicated. Anyhow, 
there is an increasing demand on behalf of the end user to 
always be able to access applications and services. A portal is 
such a doorway to the content of services and applications which 
particularly should be tailored to suit the end user 
preferences . 

Examples on portal content are information services (also 
including push content which relates to an Internet technique 
through which all information a user subscribes to automatically 
is provided to the user, or information that the service 
provider or operator means that the user should be provided 
with) . Examples on information services are weather forecasts or 
weather information in general, commercial services such as 
shopping malls, or generally any kind of information, multimedia 
services such as streaming audio/video, games, instant messaging 
and newsgroups, web based mail, access to particular communities 
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through chat-rooms. It is also desirable to be able to provide 
appealing graphical user interfaces for representing 
applications and menus on PC:s, and particularly also for WAP- 
enabled devices, in case a portal is mobile. Much effort is also 
put down on personalizing the structure and the content of 
personal portals, and to provide a possibility to control the 
interaction and behaviour of individual services and 
applications, by setting personal preferences. It is however 
difficult to provide for satisfactory access possibilities 
irrespectively of which kind of device that is used by an end 
user. Particularly when different systems need to be integrated, 
as far as session management issues are concerned, i.e. when the 
different systems (portals, services/applications, other portals 
etc.) have their own session management, the situation may get 
very complicated. 

Until now many applications are in principle exclusively 
designed for the 2G telecommunications environment and they have 
been implemented as monolithical blocks or with a proprietary 
service network to handle the specific QoS requirements for the 
respective applications. This has a consequence that such 
applications work satisfactory as isolated applications, but 
they are difficult to integrate with other applications 
developed in similar ways. Applications developed for the 
Internet (Internet protocol) environment have to a large extent 
been based on established and open de facto standards supporting 
extensive integration of different applications. Many such 
standards have been used in the 2G environment for non real- 
time critical applications. However, through the introduction of 
3G networks (3GPP) , future applications will contain a mixture 
of telecommunication and datacommunication services, mixing 
higher and lower bit rates as well as real time and non-real 
time traffic. The service networks of today are not designed to 
handle such mixtures, nor are the existing IP-based applications 
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designed for the specific characteristics concerning wireless 
networks. As can be seen there are many complicating factors 
concerning the provision of satisfactory access for end users to 
services, particularly when session management is handled by 
different session managers for different systems/entities. 

Session management of homogeneous portal environments can be 
clearly specified and may for example be performed based on the 
servlet session API (Application Programming Interface) 
specification or the session EJB (Enterprise Java Beans) 
specification. These specifications define the basic operations 
for session management, namely to create/destruct a session and 
to get, set and remove a key-value pair in a constructed 
session . 

Internet portals are usually provided with a session management 
system allowing tracking of the actions initiated by an end 
user. Such actions may for example include the actions end user 
entering the system, authentication of the end user, access by 
the end user to a portal service etc. As long as the end user 
navigates within the portal, i.e. requests access to services/ 
applications internal to the portal, which here means 
services/applications for which session management is handled 
centrally within the portal, session management can be handled 
easily / since every portal service can ask a central session 
manager, i.e. the portal session managing means, to retrieve 
information stored in the session of the end user. The sessions 
are particularly stored in storing means. However, the situation 
is different if an end user requests access to an external 
system or to a service or an application integrated with the 
portal, or an external service/application, which here means a 
service/application having an external, or its own specific 
session management. The situation can then be very complicated. 
A serious problem is that, if a service or an application (or 
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another portal), that an end user wants to access via a portal 
structure, has its own session management, the external session 
management may be incompatible to the portal session management. 
This is often the case when application service providers offer 
services to portal owners. For various reasons it may not be 
desirable to expose the external session management to the end 
user. Still further the sessions created taking into account 
also the external session management tend to get very long, i.e. 
the session identity that is used in communication with the end 
user has to contain not only the portal session identity, but in 
addition thereto also the external session identity. Often such 
lengthy session identifications can not be handled by the 
clients served by the portal. This is particularly serious if 
the end user station is a mobile device such as a WAP-device, 
which simply might not be able to handle such large amounts of 
data. Even for an end user station able to handle such amounts 
of data only for identification purposes, it involves a waste of 
resources and time. 

SUMMARY OF THE INVENTION 

What is needed is therefore a portal structure through which 
session management can be handled in an easy and efficient 
manner, also when the session management of the accessed 
systems/services/applications is handled by other, different 
session managing systems. Particularly, when a portal structure 
has its own portal session managing means and another system, 
such as a service, an application or another portal, to which an 
end user requests access, has its own, here denoted external, or 
proprietary, session managing means, an easy and efficient 
session management is needed. Particularly a seamless 
unification of session management between portals and externally 
session-managed (external) systems is needed. A portal structure 
is also needed through which the session management existing in 
other systems, such as services/ applications or portals that 
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are session-managed by third party session managing means, or 
external session managing means, can be combined and integrated 
with the portal session management. 

An arrangement is also needed through which a portal (internal) 
session management and various session management methods of 
third party or external session managed systems can be unified 
into a unified session management. Particularly a portal 
structure is needed which is able to provide an end user with 
access to services/applications for which session management is 
handled by external session managing means (third party session 
managing means), i.e. not the same session managing means as the 
portal session managing means as well as to internal 
services/applications. An end user should thus be provided with 
access to services etc. irrespectively of whether the 
services/applications (content) are located within the portal 
structure itself, or whether the applications/services and the 
content thereof reside outside the portal, i.e. are provided by 
external providers and/or are session-managed by external 
session managing means. 

Particularly a portal structure is needed which allows access by 
mobile end user stations (in addition to fixed end user 
stations) irrespectively of whether accessed services/ 
applications etc. are internally or externally session-managed. 
A portal structure is also needed through which the number of 
parameters that have to be used in communication with end users 
is reduced as compared to for hitherto known structures, and 
irrespectively of whether accessed services/applications reside 
within the portal or not, and irrespectively of whether they are 
separately or externally session-managed. Particularly a portal 
structure is needed which is capable of integrating different 
session management methods at the same time as it integrates 
Internet and WAP-based services, so that access is enabled from 
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any Internet connected PC, WAP-device or any other mobile device 
using any mobile access network. 

An arrangement for handling and integrating session management 
in a portal structure is also needed through which one or more 
of the above mentioned objects can be fulfilled. Still further a 
method for handling session management in a portal structure is 
needed, as well as a method of providing an end user with access 
to services/applications, irrespectively of whether they are 
session-managed by the portal session managing means or by 
external session managing means, through which one or more of 
the above mentioned objects can be fulfilled. 

By using a generic markup language in a portal, content of 
applications and services can be stored independently of user 
station or user device, and before showing the content of an 
application or a service, the content can be transformed into 
the format, i.e. the markup language, that can be understood by 
the end user device. One example on such a generic markup 
language is the XML (Extended Markup Language) . As a standard 
for navigation in an XML-based portal is the XLink specification 
used, which allows elements to be inserted into XML documents in 
order to create and describe links between resources. XLink 
provides a framework for creating both basic unidirectional 
links and more complex linking structures. It allows XML 
documents to assert linking relationships among more than two 
resources, associate metadata with a link and to express links 
residing in a location separate from the linked resources. XML 
is described in W3C Recommendation, 6 October 2000, Extensible 
Markup Language (XML) 1.0 (Second Edition), which herewith is 
incorporated herein by reference. 

In the following some concepts used in this document will be 
described or defined. A portal is generally a non-physical 
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entity in the Internet domain which can be described as an 
"electronic publishing space" which is owned by an individual or 
an organi zat ion, and which provides either direct access to 
information and services, or links to other entities in the 
Internet or private intranet domains, providing information and 
services to authorized end users. A portal is in its simplest 
form a regular home page or a list of links, whereas in more 
advanced forms it may offer interactive services, not only to 
those who consume what is published, but also to those who are 
granted the right by the editor to publish on the portal, as 
well as to the editor himself, regarding different aspects on 
how the portal is used. 

Wireless end users are given access through a "service" portal. 
Such a "service" portal is different from a traditional fixed 
Internet portal for PCs, and end users demand personalized 
services delivered to, and presented on, their mobile terminal 
at least as an option. In the following will however not the 
terminology "service" portal be used, but a portal (structure) 
in this document means either a conventional portal or a 
"service" portal . 

An application is one or several cooperating software entities, 
the functional focus being user interaction and usefulness for 
the end user. An application platform is a defined combination 
of software and hardware entities used to implement applications 
of a certain kind which are characterized by the functionality 
and quality of its constituent parts. 

By portal infrastructure is, in general terms, meant the 
software and hardware entities needed to either host or produce 
or generate a specific portal. Specifically it contains a portal 
core, an IP infrastructure and service enablers . 
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A service enabling means, also called a service enabler is a 
support functionality accessed via APIs (Application Programming 
Interface) raising the abstraction level and simplifying the 
application developer's task. A portal core is the core of a 
portal infrastructure, i.e. a portal core is the central part of 
a portal structure that is needed to develop a portal framework 
within which content and applications can be disclosed and 
accessed by end users in a controlled and unified manner. By a 
service network is generally meant an IP-based network, which 
consists of nodes hosting application servers, service 
capability servers, application support servers, IP 
infrastructure servers etc. Application support servers 
interface with service network resources or other external 
resources than core networks, whereas service capability servers 
interface with resources and functionality in core networks. 



In the present application a portal structure is intended to 
mean a portal core, a plurality of services and applications 
with their content and service enabling means (service 
enablers). Generally may also the connectivity and data bearer 
functionality be included. However, important for the 
functioning of the present invention are the components of the 
portal core. The problems to be solved are particularly present 
when accessed services/applications are session-managed by other 
means than the session managing means of the portal structure 
itself . 



Therefore the invention provides a portal structure, providing 
end user stations with access to services/applications which 
comprises a portal core (and service enabling means, 
connectivity means via which end user access is provided) . The 
portal core comprises a presentation arrangement, a portal 
session managing means generating and handling session related 
information, e.g. session identifications, and storing means for 
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storing session related information. The portal core also 
includes subscriber managing means, not further described. At 
least some of the services/applications comprise external 
services/applications which are session-managed by external 
session managing means generating and handling external 
application/service session related information, e.g. external 
session identifications . 

The portal session managing means comprises a session unifying 
arrangement for mapping or transforming between portal session 
identifications and external service/application session 
identification information. For communication between the portal 
core and external services/applications, the external service/ 
application external (proprietary) session identifications are 
used, whereas for communication between an end user station and 
the portal core, only the portal session identifications are 
used. Particularly the services/applications generate a generic 
markup language which, even more particularly, may be the XML 
language . 



In advantageous implementation external session identification 
information for all external services/applications active in a 
session is stored in the portal storing means, at least 
throughout the duration of the respective session, or throughout 
a predefined time period. A time period may e.g. be defined such 
that when there has been no activity in the session for the 
given time period, the information need not be stored any 
longer . 

In a particular implementation the portal structure is mobile, 
which here means that it supports access by mobile end user 
stations, such as for example WAP-devices, in addition to fixed 
end user stations. The portal structure includes rendering means 
for translating service/application data in a generic markup 
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language into a different markup language as used by / or 
understandable to, an end user station. If a generic markup 
language is used, particularly XML, data of services/ 
applications is defined in a Document Type Definition (DTD) 
5 language with an URL attribute (Uniform Resource Locator) . DTD 
is (here) an XML-document describing all the elements and their 
attributes which are allowed in all the documents that can be 
seen as belonging to the particular DTD, In one implementation 
an external system (service/application) with its own, or 

10 external, session managing means, comprises another portal. In a 
particular implementation the portal session management operates 
according to the servlet session API or the session EJBs 
specifications for defining basic session management operations. 
This means that the specifications can be used to get a session 

15 from an externally session-managed system. In this specification 
it is also referred to as a backend system, which thus may be a 
service/application which is external, at least in the sense 
that it is externally session-managed. It may also be another 
portal with its own external, (proprietary) session managing 

20 means. 

According to the invention the portal session managing means 
particularly stores information relating to end user initiated 
actions, such as end user entering the portal, end user 
25 authentication, end user access of a service/application etc. 
into the portal storing means. 

According to the invention, when an end user station requests a 
service/application from the portal, a session with a portal 
30 session identification is created by the portal session managing 
means. The request is subsequently forwarded to the requested 
service/application which, if it is an internal service/ 
application, uses the portal session identification. On the 
other hand, if the service/application is externally session- 
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managed, an external session identification is generated for the 
end user, which is used in communication between the portal and 
the service/application. For an externally session-managed 
service/ application, the external session managing means stores 
5 the external session identification information generated for a 
requesting end user for a defined time period, e.g. throughout 
the session, or until the session has been "inactive" for a 
given time period. 

10 When a subsequent call request is received from the portal, i.e. 
a subsequent call by the same end user in the same session for 
the same service/application, the generated external session 
identification is used to find the session in the 
service/application. Application data is generated and 

15 application information data is sent to the portal using the 
external session identification which, by the portal session 
unifying means, is converted into/mapped onto the portal session 
identification . 

20 In one implementation a namespace is created within the portal 
session, and for each accessed external service/application 
session, information data is stored within the namespace. In a 
particularly advantageous embodiment an external service/ 
application, or an external session managing means, creates an 

25 external (or proprietary) session with a service/application 
(proprietary) external session identification for an end user 
requesting access to the external service/application via the 
portal and introduces a metainf ormation tag, containing at least 
the proprietary or external session identification, into the 

30 data in the generic markup language, which is to be sent to the 
portal core. Particularly all data of the metainf ormation tag is 
stored in the corresponding portal session for the requesting 
end user. 
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In a particular implementation continuous navigation is provided 
to end user stations, irrespectively of where the 
service/application content is located, i.e. whether it is 
internal or external, through the introduction of metalinks to 
5 service/application data in a generic markup language, e.g. XML, 
to which the portal session id is added as a parameter. For this 
purpose the portal core comprises (first) translating means for 
processing such metalinks included in the service/application 
data. The portal core further comprises rendering means with 

10 (second) translating means for transforming the data in the 
generic markup language into a markup language understood by the 
requesting end user station, which is mobile or fixed. 
Continuous navigation as referred to above relates to a 
particularly advantageous implementation which, with advantage, 

15 may be combined with the unified session management as described 
in the present invention. The provision of continuous navigation 
by means of introduction of metalinks to the service/application 
data by the services/applications is described in the copending 
Swedish application "An arrangement and a method relating to 

20 access of applications/services" by the same applicant and filed 
on the same day as the present invention, and the content of 
which herewith is incorporated herein by reference. 

Thus, in a most advantageous embodiment the portal structure is 
25 mobile, and it supports access by mobile end user stations over 
a mobile communication network, such as for example GSM (Global 
System for Mobile communications), WCDMA (Wideband Code Division 
Multiple Access), GPRS (GSM General Packet Radio Service), UMTS 
(Universal Mobile Telecommunications System), Bluetooth (which 
30 is a short range radio technology), WAP (Wireless Application 
Protocol) etc. Advantageously the portal structure supports 
access by broadband devices such as PCs, or more generally fixed 
devices, as well as mobile devices such as WAP-devices. 
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In other terms the portal structure supports access by fixed as 
well as mobile end users stations using different access formats 
or using different markup languages for communication with the 
portal structure. 

According to one particular embodiment a service or an 
application may optionally be provided with one or more other 
metainf ormation tags in addition to metainf ormat ion tags 
containing external session identification information. 

Although the invention is not limited thereto, if a generic 
markup language is used, the generic markup language may be XML. 
The XML-data and possible metalinks are defined in a Document 
Type Definition language (DTD). A metalink .tag in XML-data 
comprises information about metalink type, a reference and 
addressing attribute (URL) containing service/application 
location information. The translating means (of the rendering 
means) translates XML-data by performing a transformation (XSL) , 
i.e. the XML-data is processed together with a transformation 
stylesheet (XSL transformation) to produce an output format, 
i.e. a markup language, appropriate for the accessing end user 
station, e.g. HTML (Hypertext Markup Language) for a fixed end 
user station and WML (Wireless Markup Language) for a mobile end 
user station. XSL is described in XSL Transformations (XSLT) 
Version 1.0, which is a W3C. Recommendation dated 10 November 
1999 and XSL Transformations (XSLT) Version 1.1., which is a W3C 
Working draft, 12 December 2000, which documents herewith are 
incorporated herein by reference. 

Particularly, at a subsequent access of the same 
service/application by the same end user in the same session, 
the stored metainf ormation containing the external (proprietary) 
session identification is forwarded from the portal session 
managing means by the session unifying means to the external 
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service/application (external session managing means), such that 
the external session as indicated by the external session id can 
be found. 



The invention also discloses an arrangement in a portal 
structure comprising a portal core with a presentation 
arrangement, portal session managing means generating and 
handling session related information, e.g. session 
identifications, and storing means for storing session related 
information. The arrangement further comprises a session 
unifying arrangement for unifying management of portal sessions 
and external sessions generated by external session managing 
means managing external services/applications. The portal 
session identification (only) is used in communication between 
the portal and an accessing end user station, and the external 
session identification information is used in communication 
between the portal and the external service/application. The 
unifying means comprises means for mapping between portal 
session identifications and external session identifications. 
Advantageously external service /application identification 
information is stored in the portal storing means in the 
respective portal session for a defined time period, e.g. 
throughout a session. The arrangement particularly comprises 
rendering means for translating service/ application data in a 
generic markup language into other markup languages, depending 
on the type of a requesting end user station, for rendering a 
service/application data output to end user stations having 
requested access to a service/application. Particularly such 
generic markup language is XML. 

In a preferred embodiment external session identification 
information is provided in metainf ormat ion tags introduced into 
the external service/application data, and more particularly the 
metainf ormation data is stored in the portal session in the 
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portal storing means storing portal session information. The 
portal session identification is particularly added to the 
external application/service data as a parameter. 

5 At a subsequent request to the portal for the same external 
service/application by an end user during an ongoing session, 
the metainf ormation is included into the request by the session 
unifying means upon forwarding the request to the external 
service/application, i.e. after mapping/transforming from portal 
10 to external session identification. 

The invention also discloses a method of session management in a 
portal structure when external services/applications, which are 
externally session-managed, are accessed. The portal structure 

15 comprises a portal core with a presentation arrangement, portal 
session managing means handling session related information and 
portal storing means for storing session related information. 
The method includes the steps of; creating a portal session with 
a portal session identification when an end user requests access 

20 to a service/application, unless a portal session already 
exists; forwarding the request to the requested external 
service/ application; creating, in or for the external service, 
by external session managing means, an external service/ 
application session, whereby an external service/application 

25 session identification is generated unless the session already 
exists for the requesting end user; whereby, in the 
service/application the following steps are performed; 
generating service/application data; introducing information 
about the external session identification to the service/ 

30 application data; returning service/application data including 
the external session identification to the portal; whereby in 
the portal the following steps are performed: mapping the 
external session identification onto the portal session 
identification; storing the external session identification into 
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the portal session in the portal storing means; sending the 
service/application data to the requesting end user using the 
portal session identification only. 

The method further includes the steps of; looking up the portal 
session in the portal storing means at a subsequent request by 
the end user for the external service/application; establishing 
if the portal session related information contains an external 
session identification; if yes, forwarding the request including 
the external session identification to the requested external 
service/application; looking up the external proprietary 
service/application session in the service/application or in 
external session managing means, using the external session 
identification; generating service/application data; adding the 
external session identification to the service/application data; 
sending the service/application data with the external session 
identification to the portal session managing means etc. In a 
preferred implementation the external service/application 
generates a generic markup language, e.g. XML. Preferably the 
step of adding external session identification comprises 
generation of, and introduction of, a metainf ormat ion tag 
containing at least external session identification to the 
external service/application data. 

The invention also discloses a method of integrating portal 
session management with the external session management of an 
externally session-managed system, which comprises the steps of; 
mapping between portal session identifications and external 
session identifications; storing information relating to 
external session identifications in portal storing means in a 
generated portal session; using the portal session 
identification in communication with an end user station; using 
information relating to the external session identification in 
communication with externally session-managed systems. 
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DETAILED DESCRIPTION OF THE DRAWINGS 

The invention will in the following be further described in a 
non-limiting manner and with reference to the accompanying 
drawings, in which: 

Fig- 1 schematically illustrates an overview of a portal 
structure according to one implementation of the 
invention, 

Fig. 2 illustrates a conceptual division of the presentation 
arrangement (layer) into a rendering functional layer 
and a service functional layer, 

Fig. 3A is a block diagram of a portal through which an end user 
first requests access to an external application, 

Fig. 3B is a block diagram as in Fig. 3A when the end user again 
accesses the application during the session, 

Fig. 4 is a flow diagram schematically describing a general 
implementation of the inventive concept, 

Fig. 5 is a flow diagram describing the flow when an end user 
accesses a portal requesting access to an external 
service/application when there is no session, 

Fig. 6 is a flow diagram describing the procedure when an end 
user subsequently accesses the same application in the 
same session, and 



Fig. 7 is a diagram illustrating the session mapping 
interactions in the session unification procedure. 



WO 02/059787 



PCT/SE02/00113 



19 

DETAILED DESCRIPTION OF THE INVENTION 

With reference to Figs. 1 and 2 an exemplary portal structure 
will be described in a quite detailed manner. Such a portal 
structure may be used in the implementation of the inventive 
concept which is described with reference to Figs. 3-7. It 
should also be clear that the invention by no means is limited 
to be implemented on a portal as described in Figs. 1 and 2, 
this portion of the description mainly being included for 
describing some exemplifying underlying concepts and the 
functioning of one portal structure as such. 

Fig. 1 thus shows one example on a portal structure 10 according 
to the invention. The portal structure 10 comprises a portal 
core 1 handling presentation functionalities, subscription and 
session management functionalities, a number of services and 
applications 2, comprising for example personal communication 
services, personal information services and Mobile E-Commerce 
services. In brief it is not important which kind of services 
that are provided and the inventive concept is applicable to any 
kind of service, content and application. When explaining the 
inventive concept in a more detailed manner (Figs. 3-7), when an 
end user requests access to a service or an application, any 
service or application (or content) is meant and can be seen as 
conceptually included in the portal structure, although some of 
the services and applications actually are located outside the 
portal structure and are provided by any external service 
provider, which in this document however are denoted external in 
case they are externally-session managed, i.e. if they are not 
session managed by the portal session managing means. 

The portal core structure 1 further includes a layer 3 including 
a number of service enabling means, also called service enablers 
31-37, 38A-38D. The service enablers are among other things 
involved in authentication and basic services such as gateways 
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and IP infrastructure. In this figure some examples on service 
enablers are given such as unified messaging 31, IP 
infrastructure 32, AAA-Server 33, notification support 34, 
charging support 35 and operation and maintenance support 36. 
b Further examples of service enablers are mobile positioning 
system 37, WAP gateway 38A, SMS- C gateway 38B, multimedia proxy 
38C, mobile E-pay 38D etc. It should be clear that some of these 
service enablers are more or less mandatory, whereas others are 
optional . 

10 

The portal structure is here also seen as including a 
connectivity or a (mobile) bearer layer comprising the mobile 
base stations and switching nodes, such as BTS (Base Transceiver 
Station), BSC (Base Station Controller), MSC (Mobile Switching 

15 Center) nodes etc. Which the nodes are, depends on which mobile 
network access is provided over, e.g. GSM. For GPRS or UMTS 
corresponding nodes are included in this layer; for example GGSN 
(Gateway GPRS Support Node) . Whichever is the network, the 
network is the data bearer for the portal for access of mobile 

20 devices such as WAP-devices (Wireless Application Protocol) . In 
Fig. 1 it is supposed that the accessing end user station 
comprises a WAP-telephone 5. 

One example on such a portal structure is the Ericsson WISE™ 
25 Portal. 

Internal applications or services can be seen as applications 
leveraging the service enablers and connectivity layers to add 
application specific values to mobile Internet applications of 
30 various categories, for example mobile services, personal 
communications as unified messaging or mail services, and 
personal information services. The information may be retrieved 
by the user through searches, but the information may also be 
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provided to the end user by means of the push technology. This 
is open to end user customization. 

It is advantageously supposed that the portal supports access by 
5 mobile end user stations, such as WAP-telephones 5 over a mobile 
network. Therefore nodes or components of the relevant mobile 
network have to be provided in mobile network connectivity and 
data bearer layer. In Fig. 1 a component denoted ISP network, 
Internet Service Provider network, is disclosed. This is an 
10 optional component which may be included or not . 

In the layer comprising the service enablers 3 some types of 
service enablers are mandatory whereas other are not. Some of 
the service enablers are as seen as important components for 

15 providing mobile Internet functionalities. Some of the service 
enablers are seen as one part of the interface components 
between Internet and the mobile network. One component is here 
denoted IP infrastructure 32. An optional service enabler 
comprises the notification support 34, which generally is an 

20 optional component enabling applications to send out filtered 
notifications to end users using the SMS (Short Message Service) 
channel, but it may also be adapted to include other channels 
supporting WAP technology and 3G (3GPP) technology. Charging 
support enabler 35 may be provided to allow for flexibly 

25 choosing charging events. Another service enabler 36 relates to 
operation and maintenance support and generally it is a 
mandatory component. A service enabler WAP gateway 38A is an 
optional service enabler WAP gateway/proxy forming the access 
point between the wireless world and the Internet world. It 

30 supports mobile clients accessing the WAP gateway/proxy using 
GSM circuit switched data or WAP over SMS (SMS over MAP (Mobile 
Application Protocol)). The client uses a WAP enabled browser in 
the mobile device to connect to the WEB-server where the desired 
WAP application resides. Another service enabler, mobile 
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positioning system, 37 is an optional component allowing sending 
the position of a user to the application requesting it. Another 
service enabler is a multimedia proxy 38C responsible for 
transmitting multimedia data over GPRS or UMTS. This however is 
5 an optional service enabling means. Also SMS-C (centre) gateway 
38B is an optional component responsible for sending or 
receiving, storing and forwarding short messages between mobile 
stations and servers. Proprietary protocols are used for 
communication with applications. Mobile E-pay 38D is a component 

10 offering the basic functionality for Mobile E-Commerce and it is 
an optional component. AAA-Server 33 is a service enabling 
component relating to authentication, authorization and 
accounting. These functionalities may be provided in other 
manners but they may also be integrated in a functionality 

15 server, for example enabling traffic based charging and period 
charging. Such a component, either if it is split up into 
different components or comprises a single component, which is 
common for a number of functionalities, is mandatory, and in an 
advantageous implementation it is used for session management 

20 functionalities . 

However, it should be clear that Fig. 1 merely shows examples on 
service enabling means that may be provided in a service 
enabling layer 3. At least some of the illustrated service 
25 enablers may be excluded, still others may be included etc. 

The portal core, or the portal core layer, handles, as referred 
to above, presentation, subscription and session management and 
service tiers comprising a number of internal (and external) 
30 application servers. The core 1 comprises a presentation 
arrangement 11 which enables mobile portal presentation on 
multiple devices using multiple protocols. It may e.g. be XML 
driven (or more generally driven by a generic markup language) . 
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In one implementation it is a Java™ and XML driven multimarkup 
language capable presentation module. 

The presentation arrangement 11 comprises a rendering means (a 
5 rendering engine) which in one implementation uses XML/XSLT 
technologies to ensure that information presented by services 
within the portal is displayed in a standardized way, regardless 
of which type of end user station (or browser) an end user uses 
when accessing the portal structure. Through the use of a 

10 generic markup language, for example XML/XSLT, the "look and 
feel" of content presented to end users may be customized. XSL 
is an abbreviation for Extensible Style Sheet Language. The 
Swedish patent application "An arrangement and a method for 
presentation customization in a portal structure", which is an 

15 application filed on the same date and by the same applicant as 
the present application, and the content of which herewith is 
incorporated herein by reference, relates to user customization 
in a portal structure as described herein, and particularly it 
is concerned with "look and feel" customization. 

20 

The functionalities within the portal core 1 and of the 
presentation arrangement 11 in particular will be further 
described with reference to Fig 2. 

25 The portal core 1 also includes the subscription manager. In one 
implementation subscription manager component information is 
stored in an LDAP (Lightweight Directory Access Protocol) 
directory and it is managed by a service called subscription 
manager. The subscription manager includes functions for the 

30 operator to create, maintain and delete subscriber information 
in the subscriber database. It also enables the end user of the 
system to subscribe to the services in the system. In a 
particular implementation a self-registration and self-service 
concept is supported in order to minimize costs by minimizing 
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the workload on a customer care center. Information about 
available services may also be kept in the directory referred to 
above, and handled by the subscription manager. As a new service 
is entered into the directory, it will immediately be available 
5 for subscription by the end users. In the directory end users 
can be grouped so as to make new services available only to 
defined sets of end users. The subscription manager 12 can be 
interfaced with an existing customer care system through the 
application programming interface (API) it uses. 

10 

The session manager 13 is a general mechanism that can be used 
by applications and services. It comprises an interface to . a 
subsystem for keeping track of all visitors to the portal and to 
provide the profile information of the visitors. When an end 

15 user enters the system/application, a session id entity is 
allocated and it is stored for that particular end user until 
logging out of the service or when the end user has been idle 
for a preset period of time. When a participating application 
starts, it first checks if there is an active session id for a 

20 particular user and if there is one, it would be able to resume 
from where the session was broken. The session management 
functionalities according to the inventive concept will be 
described below with reference to Figs. 3A-7 . 

25 Finally, the portal core structure 1 here comprises two 
"internal" application servers 14A, 14B and one or more external 
application server 14C. The external application server 14C 
contains links to external application servers running existing 
services. In one implementation the service tier comprises three 

30 classes of services, of which a first is developed in compliance 
with the portal core specifications implemented using the portal 
core environment. A second service class relates to services 
which not necessarily are implemented in the portal core 
environment, such as for example an external e-mail system 
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running on a non-portal core environment adapted to present 
itself through the portal core presentation. The third service 
class relates to external services which do not comply with the 
portal core service development or presentation architectures. 
5 This will be further explained with reference to Fig. 2. 

In the following the portal core, and specifically the 

presentation arrangement, comprised in the presentation layer, 

will be more thoroughly described, first with a general 
10 reference to Fig. 2. 

The service tier in one advantageous implementation comprises 
three service classes. The service class portal core service 
(pcoreservice) complies with the specifications of the portal 

15 core and it is used to leverage the portal core characteristics. 
In one implementation the services are implemented using the 
J2EE IBM WEBSphere Environment (an application server used to 
develop programmatic services involving logic, algorithms etc.). 
Such services generally have three or four tier architectures 

20 deploying JSP (Java Server Pages) on the front end, Java 
servlets and Enterprise Java Beans (EJB) in the middle layer and 
various entities on the back end. The second service class are 
the integrated portal core services (integrated pcore services) 
which leverage pcore presentation services but which are not 

25 necessarily implemented in the portal core J2EE environment, 
e.g. an external e-mail system running on a non-portal core 
environment, but adapted to present itself through the portal 
core presentation. The third service class, pcore external 
services, neither complies with the portal core service 

30 development nor with the presentation architectures but the 
services included in this class may e.g. be triggered to the 
portal core. 
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In one implementation there are two types of service options 
available within the service layer. One may consist of services 
provided by Broadvision (CORBA) for creating optimized rule 
based and personalized services connected to commerce and 
5 retail, and optimized for content delivery by a matching engine 
operating on content, profile and business rules. The other 
service type relates to programmatic services for example 
requiring algorithms, logic etc. which are not easily built in 
an optimized content delivery system. If these services are of 
10 pcore service class, then they may be industrialized for IBM 
WEBSphere J2EE environment and if they are of integrated 
services class and running in an external service server, they 
are adapted to the portal core presentation. 

15 A service needs specifications including elements on the 
rendering functionality of the presentation layer as well as 
relating to the service layer functionality, i.e. schemes and 
logic. The portal core presentation architecture may, as 
referred to above, in one advantageous embodiment implement the 

20 J2EE architecture for the mechanisms of creating and employing 
services in specific elements or for defining services. However, 
the invention is not limited to a portal structure using J2EE 
and Broadvision which merely are given as examples. 

25 The presentation layer is conceptually split-up into two tiers, 
one rendering layer residing in the portal core itself and a 
service layer available to any service that wants to present its 
content through the portal core presentation structure. The 
rendering layer in one advantageous implementation uses XML/XSLT 

30 technologies. Thereby it is also ensured that information 
presented by services within the portal can be displayed in a 
standardized way irrespectively of which is the end user 
station, i.e. irrespectively of which kind of end user station 
the end user uses when accessing the portal. Through the use of 
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XML/XSLT it can be assured that a unified "look and feel" of 
content is presented within the presentation space. 

If XML is used as a generic markup language, a service produces 
5 an output in the form of an XML document formatted using 
structure information from a pcore DTD. The XML output from the 
service is then used to feed the presentation engine of the 
presentation arrangement. The presentation engine uses pcore SS 
and pcore grid information associated with the pcore DTD of the 
10 XML document supplied by the service to generate the desired 
interface. Services which do not produce XML from a pcore DTD 
are particularly also able to present themselves through the 
presentation services . 

15 As referred to earlier, the portal structure is advantageously 
able to handle different devices such as WAP-phones and 
broadband devices such as PCs, or the browser used thereby. A 
portal core structure platform and the logic in it are 
particularly totally separated from the presentation layer 

20 functionality, which makes it very easy to implement support for 
all different types of clients, even voice and speech 
synthesizers. By using for example XML/XSL, it is very easy to 
implement support for instance for a new type of WAP-display 
size. It is also possible to adapt the rendering process to 

25 various WEB-devices, existing and future hand-held devices, 
voice browsing and interactive TV. 

In one particular implementation the WEB-interf ace is composed 
of square elements also denoted bricks. A brick is a container 
30 of a service, a picture or an application, displayed on the 
screen of the end user station. Using such bricks or containers, 
it is possible to customize the portal. A brick is thus an 
application created to be used inside the portal structure, 
which has a link to the application. The application has to 
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provide display information to the portal when it wishes to 
render the brick. Advantageously a brick can appear in more than 
one format. The disposition of the bricks or containers 
represent a so called brick interface. In order to enable easy 
5 navigation, the WAP-interface may in one implementation be 
structured in the same way. In the WEB-interf ace the user is 
presented with a list of available bricks. Each brick contains 
an application, service or a background picture that can be 
included in the user's built WEB-site. A brick can also be a 

10 pre-conf igured service from an external company or provider. A 
Brick-grid is a non-visual representation of a customized 
portal. Depending on device, the brick grid is represented in a 
way that is most suitable for the device in use. The grid can be 
designed in many ways as well as the way the bricks are 

15 presented and organized, for example with tags. The brick grid 
is stored in a generic format and it is device/end user station 
independent . 

Preferably the end user authenticates himself towards the portal 
20 with a one time login which will give the end user access to all 
the functionality within the portal. Any authentication towards 
connected or to external content or service providers is handled 
by the platform security system. Advantageously each application 
or service within the portal can be personalized to fit the 
25 needs of the end user and each application can be personalized 
for different devices. This is particularly advantageous when an 
end user wants to limit the amount of data sent to another end 
user station with limited capacity to present larger amounts of 
data, e.g. a WAP-phone. It is possible to select one application 
30 more than once and to give each of the different instances its 
own personalization . 

Above one example on a portal structure has been described in 
which the inventive concept can be implemented. However, the 
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invention as such is of course not limited to be implemented in 
such a portal but it is based on the assumption that a portal 
structure is provided which is able to provide end users, i.e. 
entities accessing the portal, with access to 

services/applications. For each end user a session is created by 
the portal and each session contains end user specific data. A 
service/application may be external or internal. In this context 
an internal application or service is defined as an application 
or service using the session management of the portal, whereas 
an external application or service is defined as an application 
or service using an external session management, which means 
that it may provide for the session management itself, or it may 
be session-managed by a third party. 

The inventive concept will in the following be described in 
detail with reference to Figs. 3A-6. 

Figs. 3A, 3B show an implementation in which it is supposed that 
the portal structure supports access by mobile as well as fixed 
end user stations. In an advantageous implementation access to 
the portal structure itself, for different types of end user 
stations, is enabled even if the types are not known by the 
portal structure. This may be carried out as described in the 
Swedish patent application "Arrangement and method relating to 
end user stations accessing a portal", filed on the same date 
and by the same applicant as the present application, and the 
content of which herewith is incorporated herein by reference. 

Fig. 3A is a schematical illustration of an end user station 5, 
which here is a WAP-device accessing the portal core 1 of a 
portal structure to get access to an external application 26. In 
the portal core only the means that are of interest for the 
functioning of the present invention are illustrated, namely 
presentation arrangement 11 with rendering means 15, request 
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broker 16, portal session managing means 13, session unifying 
means 50 and portal session storing means 51. 

If the end user station 5 wants access to an external 
5 application 26, a request (I 0 ) is provided to the session 
unifier 50, and, as it is the first transaction of the 
connection, i.e. there is no session available for end user 5 
relating to the external application 26, a session is created by 
portal session manager 13, which receives the request (IIo) from 

10 the session unifier 50. The session contains user specific data 
and it is stored into the portal storing means 51. A portal 
session identification, or briefly a portal session id, is 
created. The session unifier 50 also forwards the request (III 0 ) 
to the request broker 16, which passes it on to the external 

15 application 26, (IV 0 ) . The external application detects that 
there is no (external) session for the requesting user, 
generates data (e.g. XML) , creates an external session with an 
external session id, and introduces the external session id as a 
metainf ormation tag to the (XML) data, which subsequently is 

20 sent as a reply to the portal request broker 16 (V 0 ) containing 
the metainf ormation tag. The data with the metainf ormation tag 
is passed on to the rendering means 15, (VI 0 ) , which detects the 
metainf ormation tag and passes it on to the session unifier 50, 
which transforms it to the portal session id which then is 

25 returned to the rendering means, (VII 0 ) - In the rendering 
process the portal session id is written into the reply data 
which is passed on to the request broker 16 (IX 0 ) for sending it 
on to the end user station 5. 

30 In Fig. 3B it is supposed that a session already does exist and 
end user station 5 again tries to access application 26 in the 
same session, (I). The session unifier 50 retrieves the user 
portal session from the portal session manager 13 (portal 
storing means) (II) . The session unifier 50 retrieves service/ 
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application data for the service/application to be accessed, 
e.g. the external (backend) session id, (III). The external 
session id is then passed on to the request broker 16 (IV), 
which calls the external application 26, (V) . The application 
5 generates data (e.g. XML) which includes the external session id 
in the metainf ormation tag and sends it to the portal, (VI). The 
request broker forwards the data to the rendering means 15 for 
rendering (VII) . The rendering means 15 communicates with the 
session unifier 50, which maps the external session id onto the 
10 portal session id and returns the latter to the rendering means 
15, (VIII). The rendering means then writes the portal session 
id into the reply intended for the end user station 5, (IV) . Via 
the request broker the reply is sent to the end user station 5 
(X) . 

15 

For access of an internal application the portal session id is 
used both for communication between the portal and the internal 
application and for communication between the end user station 
and the portal core. 

20 

If the application generates a generic markup language, e.g. 
XML, the XML data is also translated in the rendering means 15 
and rendered and output to the end user station 5 in the markup 
language understandable to the end user station, e.g. HTML if it 
25 is a PC and WML if it is a WAP-device. 



This means that, for communication between the end user station 
and the portal, only the portal session id is used once assigned 
whereas, between the portal and an external application, only 
30 the external application session id is used, once generated. 

In a portal structure implementing to the inventive concept a 
session management unification framework consisting of the 
session unifier is provided. The session unifier provides a 
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generic one-to-many session mapping mechanism, i.e. if there are 
a plurality of external systems (applications, services, 
portals) having their own session management, the session 
unifier is able to transform portal sessions to the sessions of 
external systems and vice versa. 

The procedure will be described in general terms with reference 
to the flow diagram of Fig. 4. It is thus supposed that a 
request for an application, here denoted C, is received in the 
portal structure from end user U, 100. The portal checks if 
there is a scission available in the storing means for end user U 
relating to application C, 101. If not, a portal session is 
created which is assigned a portal session id, 102. It is 
established whether application C is externally session-managed, 
103. If not, the application will use the portal session id in 
communication with application C and with end user U, 104, and 
there is no need of unification of sessions. If, however, 
application C is externally session-managed, the request is 
forwarded to application C, 106 (of course also if the 
application is internally session-managed, i.e. uses the portal 
session management, the request is forwarded to the application 
etc., but this is not relevant for the inventive concept and 
will therefore not be further discussed herein) . In application 
C (or more generally the external system), it is examined if 
there is a session available for end user U, 107. If not, an 
external application proprietary session with an external 
session id, also denoted an external (application) id is 
generated, 108. Application data is generated which is provided 
with information on the external session id. A response 
containing the application data and the information about 
external session id is sent to the portal, 109. 

When the reply is received within the portal, the external 
session id information is stored in the portal session created 
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for end user U for application C, which portal session is stored 
in the portal session storing means, 110. Subsequently, for 
further communication between the end user and the portal, the 
portal session id is used. Information on the external session 
id is included in communication with application C, 111. 

If in step 101 above it was established to that there was a 
session available in the storing means, for an external 
application the information about the external session id, is 
particularly found, 105. Then the portal session id is used in 
communication between the end user and the portal, whereas the 
external session id is used for communication between the portal 
and the application as referred to above, 111. If however there 
was no information stored about an external session id in the 
portal session stored in the portal storing means, 105, it may 
indicate that the application is internal and the portal session 
id is used in communication both with application C and with end 
user U. 

Step 103 above may give the impression that there has to be a 
separate detection as to whether an application is external. 
This may however be inherently detected, for an already existing 
session, when the portal session is fetched by the session 
unifying means from the portal storing means via the portal 
session managing means. For a new session it may be detected as 
the response is received from the application which then 
contains a meta information tag with the external session id, 
particularly by the rendering means. 

Fig. 5 is a flow diagram describing somewhat more in detail, for 
a particular embodiment, the procedure when a request from an 
end user Ul is received in the portal relating to an external 
application A for the first time, i.e. there is no session, 200. 
The portal session managing means detects that there is no 
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session for Ul relating to application A, 201. The portal then 
creates a session for end user Ul and application A with a 
portal session id, 202. Subsequently the request is forwarded to 
application A, 203. Application A detects that there is no 
session for Ul, 204 . Application A then creates a proprietary 
external session for Ul and a metainf ormation tag with at least 
an external session id, i.e. with the identity of the created 
session, 205. The application also generates application data, 
in this embodiment in XML, and sends the application data with 
the metainf ormation tag to the portal core, 206. Thus, in the 
XML data there is a metainf ormation tag containing the 
application session id. It may for example look like: 

<metainfo name="application_session_id" value="4711 n /> 

The portal session unifying means maps the external session id 
onto the portal session id for Ul, 207. The portal session 
managing means stores the metainf ormation data, particularly all 
metainf ormation data if, in an advantageous implementation, not 
only metainf ormation relating to the session id is included, but- 
also other data, into the portal session, 208. In one 
implementation the application data also contains metalinks 
referring to other services/applications which may be processed 
and translated by translating means, as further discussed in the 
copending patent application "An Arrangement and A Method 
Relating to Access of Applications/ Services", and the session 
id of the portal is added as a parameter. 

The rendering means of the portal core renders the application 
data, i.e. translates it into a format appropriate for the end 
user station, and sends it to end user Ul using only the portal 
session id, 209. 
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Fig. 6 is a flow diagram describing the procedure when end user 
Ul tries to access applications A once again during the same 
session. Thus it is supposed that a subsequent request for 
application A is received in the portal from Ul, 210. This means 
for example that the end user Ul clicks on a link in his browser 
to application A which link has a parameter to the portal 
session id. Via the session unifier the portal session managing 
means looks up the portal session for Ul using the portal 
session id, 211. It is detected that there is metainf ormat ion 
contained in the portal session for Ul, 212, relating to 
application A. The portal request broker contacts the 
application and includes the metainf ormat ion as parameters and 
forwards the request to application A, 213. The metainf ormat ion 
comprises the external session id, which thus will be sent to 
the application, i.e. used in communication with application A. 
Application A uses its external session id as included in the 
metainf ormation to look up the external session for the end user 
Ul, 214. The application creates application (XML) data, 
includes the metainf ormation tag into the XML data and sends XML 
data with the metainf ormat ion tag to the portal, 215. Then the 
flow proceeds as in steps 207, 208 of Fig. 5 (216) etc. 

According to one implementation the external application, or 
more generally the external system, also denoted the backend 
system, provides the following operations in order to make the 
session unifying means (session unifier) functional: 

1. BackendSession bs = backend, createSession ( ) 

2 . Bs . updateSession ( ) 

3. Stream s = backend . serializeSession (BackenSession bs) 
The session unifier implements the following operations: 



1. PortalSession ps = 



Portal . get Session ( ) 
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2. BackendSession bs = 

Ps . getBackendSession (backendService) 

3. ps. callBackendService (backendService) , bs) 

4 . ps . storeBackendSession (backendSersvice, bs) 

The session unification procedure thus functions as follows 
according to this implementation: 

1. The unifier calls ps . getSession () to retrieve the portal 
session associated with the request/call for the service/ 
appl icat ion . 

2. The unifier calls bs = ps . getBackendSession (backendService) 

3. The unifier calls ps . callBackendService (backendService, bs) 

4. If there is no backend session for the user (bs = 0), the 
backend calls bs = backend, createSession ( ) and sends this 
session along with the reply to the portal. Otherwise, the 
backend calls bs . updateSession ( ) , and sends this along with 
the reply to the portal. Sending the backend session is 
accomplished by calling 

backend. serial i zeSession (bs) . 

5. The portal stores the backend session by calling 
ps . storeBackendSession (backendService, bs) 

Fig. 7 is an interaction diagram describing the steps of the 
session unification procedure described above. 

P. getSession ( ) can be implemented by any session management 
system following e.g. the Servlet Session API. 

P. getBackendSession (backendService) can be implemented by 
creating a namespace within the portal session for each 
backendService accessed, and storing, within the namespace, the 
backendService related data. 
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To reduce the bandwidth requirements, B . serial iseSess ion ( ) can 
be implemented by sending only an identifier of the session from 
the backend system. 

It is an advantage of the invention that through provision of 
session unification, a seamless integration of different session 
management systems into one unified session management is 
enabled. For portal structures this may considerably reduce the 
integration time between portal and external application service 
providers. Particularly for mobile portals, supporting access 
also by mobile stations, such unifying of session management 
provides a powerful means to reduce the amount of data that has 
to be sent to wireless end user stations through converting 
lengthy backend-session data into short unified sessions. Access 
by mobile end user stations, such as WAP-devices, to externally 
session managed systems might otherwise not even be possible due 
to the large amount of data that has to be transferred in case 
both a portal session id and an external session id have to be 
included in communication with the end user station, since such 
amounts of data may be unacceptable for a mobile end user 
station. Even if an end user station is able to handle such 
amounts of data only for identification purposes, it is a waste 
of resources and time. 

It should be clear that the invention is not limited to the 
specifically illustrated embodiments but that it can be varied 
in a number of ways within the scope of the appended claims. 
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CLAIMS 

1. A portal structure providing end user stations with access to 
services/applications, comprising a portal core, (service 
enabling means, connectivity means via which end user access is 
provided) and a number of services/applications, said portal 
core comprising a presentation arrangement, portal session 
managing means generating session related information, e.g. 
session identifications, portal storing means for storing 
session related information (and subscriber managing means), 
wherein at least some of the services/applications comprise 
external services/applications, or are provided by external 
systems, implementing external session managing means generating 
external session identifications, 
characterized in 

that the portal structure further comprises session unifying 
means for mapping between ' portal session identifications and 
external session identifications and in that for communication 
between the portal core and external services/applications the 
external service/application external identification is used as 
session identification, whereas, in communication between an end 
user station and the portal core, only the portal session 
identification is used as session identification. 

2. A portal structure according to claim 1, 
characterized in 

that the services/applications generate a generic markup 
language . 

3. A portal structure according to claim 2, 
characterized in 

that the generic markup language is XML. 
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4. A portal structure according to any one of claims 1-3, 
characterized in 

that external service/application proprietary external session 
5 identification information for all external services/ 
applications active in a session is stored in the corresponding 
portal session in the portal storing means for a defined time 
period, e.g. throughout the duration of the respective session. 

10 5. A portal structure at least according to claim 2, 
characterized in 

that the presentation arrangement comprises rendering means for 
translating service/ application data in the generic markup 
language into a different markup language used by an end user 
15 station. 

6. A portal service according to claim 5, 
characterized in 

that it is mobile, i.e. it supports access by mobile end user 
20 stations, e.g. . WAP-devices, in addition to fixed end user 
stations . 

7. A portal structure at least according to claim 2, 
characterized in 

25 that data representing services/applications in the generic 
markup language are defined in a Document Type Definition (DTD) 
language with an URL-attribute. 

8. A portal structure according to any one of the preceding 
30 claims, 

characterized in 

that an external system with an external proprietary session 
managing means comprises another portal. 
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9. A portal structure according to any one of the preceding 
claims, 

characterized in 

that the portal session managing means operate according to the 
servlet session API or the session EJB:s specifications defining 
basic session management operations. 

10. A portal structure according to any one of the preceding 
claims, 

characterized in 

that the portal session managing means stores information 
relating to end user initiated actions such as end user entering 
the portal, end user authentication, end user access of a 
service/application etc. into the portal storing means. 

11. A portal structure according to any one of the preceding 
claims, 

characterized in 

that upon reception of an end user request for a 
service/application, a portal session with a session 
identification is created by the portal session managing means, 
and when the request is forwarded to the service/application the 
service/application uses the portal session identification 
information if it is an internal service/ application whereas 
the service/application is provided with an external 
(proprietary) session identification if it is managed by an 
external session managing means. 

12. A portal structure according to claim 11, 
characterized in 

that for a service/application managed by external session 
managing means, the external session managing means stores the 
external, session identification information generated for a 
requesting end user for a defined time period, e.g. throughout 
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the duration of the session, and in that when a subsequent call 
request is received from the portal during the session, service 
application data is generated and a reply is returned to the 
portal core comprising the service/application data and the 
5 external session identification, by the unifying means is 
converted/mapped to the portal session identification such that 
the service/application data can be forwarded to the end user by 
using the portal session identification only. 

10 13. A portal structure according to claim 12, 
characterized in 

that a namespace is created within the portal session for each 
accessed service/application and in that the external session 
information data at least including external session 
15 identification is stored within the namespace. 

14. A portal structure according to claim 2, 11 or 12, 
characterized in 

that an external service/application creates an external 
20 proprietary session with an external service/application 
external (proprietary) id for an end user requesting access to 
the external service/application via the portal and introduces a 
metainf ormation tag containing at least the external 
(proprietary) session identification into the service/ 
25 application data in the generic markup language, to be returned 
to the portal core. 

15. A portal structure according to claim 14, 
characterized in 

30 that all data of the metainf ormation tag is stored in the 
corresponding portal session for the requesting end user. 



16. A portal structure according to claim 15, 
characterized in 
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that the portal core comprises first translating means for 
processing possible metalinks included in the service/ 
application data in the generic markup language to which the 
portal session identification is added as a parameter and in 
5 that the portal core further comprises rendering means with 
second translating means for transforming the * data in the 
generic markup language to a markup language understandable by 
the requesting end user station. 

10 17. A portal structure according to claim 16, 
characterized in 

that for a subsequent access of the same service/application by 
the same end user in the same session, the stored 
metainf ormation containing the external session identification 
15 is forwarded from the portal session unifying means) to the 
external service/application such that the external 
service/application is able to find the external session as 
indicated by the external, session identification. 

20 18. An arrangement in a portal structure comprising a portal 
core with a presentation arrangement, portal session managing 
means generating session related information, at least portal 
session identifications and portal storing means for storing 
portal session related information, 

25 characterized in 

that it comprises session unifying means for unifying management 
of portal sessions and external sessions generated by external 
session managing means managing external services/applications, 
that only the portal session identification is used in 

30 communication between the portal and an accessing end user 
station and in that the external session identification is used 
in communication between the portal core and the external 
service/application, and in that the unifying means are used for 
mapping/transforming between portal session identifications and 
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external, session identifications of external services/ 
applications . 



19. An arrangement according to claim 18, 
5 characterized in 

that external service/application proprietary, external session 
identification information is stored in the portal session to 
which it is mapped for a defined time period, e.g. throughout a 
session . 

10 

20. An arrangement according to claim 18, 
characterized in 

that the presentation arrangement comprises rendering means for 
translating service/application data in a generic markup 
15 language into other markup languages depending on the type of a 
requesting end user station for rendering service/application 
data output to end user stations having requested access to a(n) 
service/application into a markup language understandable by the 
end user station. 

20 

21. An arrangement according to claim 20, 
characterized in 

that the generic markup language is XML. 



25 22. An arrangement according to any one of claims 18-21, 
characterized in 

that external session identification information is provided in 
a metainf ormation tag introduced into the external service/ 
application data and in that the metainf ormation data is stored 
30 in the corresponding portal session in the portal storing means 
storing portal session-information, and in that the portal 
session identification is added to the external application/ 
service data as a parameter in communication with the end user 
station, replacing the external session identification. 
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23. An arrangement according to claim 22, 
characterized in 

that for a subsequent request to the portal for the same 
5 external service/application by an end user during a session, 
the metainf ormat ion is included into the request when forwarded 
from the portal core to the external service/ application. 

24. A method of session management in a portal structure 
10 comprising a portal core comprising a presentation arrangement, 

portal session managing means handling session related 
information and portal storing means for storing session related 
information, comprising the steps of: 

creating a portal session with a portal session 
15 identification when an end user requests access to a service/ 

application, unless a portal session already exists; 
forwarding the request to the requested external service/ 
application if the requested service/application is 
externally session managed; 
20 - creating in the external session managing means an external 
service/application proprietary session identification for 
the requesting end user unless a session already exists; 
generating service/application data in the service/ 
application; 

25 - introducing information about the external session 
identification into the service/application data; 
returning service/application data including external session 
identification to the portal; 

mapping the external session identification to the portal 
30 session identification; 

storing the external session identification in the 
corresponding portal session means; 

sending the service/application data to the requesting end 
user using only the portal session identification. 
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25. A method according to claim 24, 
characterized in 
that it comprises the steps of: 

in the portal: 

looking up the portal session in the storing means at a 
subsequent request by an end user for an external service/ 
application during the session; 

establishing if the portal session related information 
contains an external session identification, if yes; 
forwarding the request including the external session 
identification to the requested external service/application; 

in the external session managing means or in the external 
service/appl ication: 

looking up the external service/application session; 

generating service/application data; 

adding the external session identification to the service/ 
appl icat ion data; 

returning the service/application data with the external 
session identification to the portal session managing means; 

in the portal: 

replacing the external session identification by the 
corresponding portal session identification; 

sending the service/application data to the end user station 
using the portal session identification only. 

26. A method according to claim 24 or 25, 
characterized in 

that the external service/application generates a generic markup 
language, e.g. XML. 

27. A method according to claim 26, 
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characterized in 

that the step of adding external session identification comprises 
generation of and introduction of a metainf ormation tag 
containing at least external session identification to the 
service/application data . 



WO 02/059787 



PCT/SE02/00113 



1/8 



CO 

o<5§ 

oo »— 
u-j <C 



or Q- 

i . i Q_ 
OO <C 

OJ 



ae or 

CD CD 



<C CO I ) 



en 

Li_l 

CD 
L-J 
i 



CO 
CD 



"OJ 



ID 

o dc 

z: oo 



I/O 



OJ 

3V 



U_J 

oo 

CD 



CD 

OO 

or 



CC 
CD 

<C 
LD 



Al 



ID 



OJ 



z: 
z: 
o 



CD 
OO 



ao =J 

CD <C 



OJ ^ 




OO 
> CO 

C£ <c 

UJ z 
OO LxJ 



u, , or 

UJ^LU 

Z ^ °Z 
Z ffi < 

oguj 



or 

CD 
^ Cl- 
CD OO 



LD . 

LDCD 
Q_ 
<C Q_ 
DZ ZD 
l_J OO 



on 



I — Q_ 

cd : 

OO 



or 

<C U_J 
<C OO 



. or 
Q= oo 



OsJ 





LD 








LD 


CD 


<C 


U-J 


OO 


y_ 


OO 




U_J 


ID 


z: 




WO 02/059787 PCT/SE02/00113 



2/8 



RENDERING LAYER 



RENDERING ENGINE 



PCORE 
SS 



1 JSP 
1 J2EE 



PCORE 
GRID 



PCORE 
DTD 



[ XSL 1 | XMLP 



SERVICE LAYER 



PCORE 
SERVICE 



INTEGRATED 
PCORE SERVICES 



PCORE EXTERNAL 
SERVICES 



JAVA SERVLET 



EJB 



Fig. 2 



WO 02/059787 



PCT/SE02/00113 



3/8 



26' 



EXTERNAL 
APPLICATION 



. v (EXTERNAL 
IV (T^ X 0 SESSION ID.) 




PORTAL / 
STORE 



51 



13 



PORTAL SESSION 
MANAGER 



REQUEST 
BROKER 



PRES. 
ARR. 


RENDERING 
MEANS 

15 


11 






(PORTAL SESSION ID.) 



WAP 



Fig.3A 



WO 02/059787 



PCT/SE02/00113 



4/8 



26— Ni 



EXTERNAL 
APPLICATION 



(EXTERNAL y 
SESSION ID.) 




(EXTERNAL 
SESSION id.: 



PORTAL / 
STORE 



51 



C 



13 



PORTAL SESSION 
MANAGER 



REQUEST 
BROKER 




VII 



IX 



PRES. 
ARR. 


RENDERING 
MEANS 

15 


11 





WAP 



(USER CALL APPLICATION) 

X 



(PORTAL SESSION ID.) 



Fig.3B 



WO 02/059787 



PCT/SE02/00113 



5/8 



REQUEST FOR APPLICATION C RECEIVED 
IN PORTAL FROM END USER U 



100 




104 



2. 



USE PORTAL SESSION 
ID. IN COMMUNICATION 
WITH APPL. C AND 
WITH END USER U 



APPL. DATA WITH INFO ABOUT EXTERNAL 
SESSION ID. SENT TO PORTAL 



EXTERNAL SESSION ID. 
IN PORTAL SESSION 



INFO STORED 



I 



PORTAL SESSION ID. USED IN COMMUNICATION 
BETWEEN END USER AND PORTAL. INFO ON 
EXTERNAL SESSION ID. INCLUDED IN 
COMMUNICATION WITH APPL. C 



•109 



110 



■111 



Fig. 4 



WO 02/059787 PCT/SE02/001 13 



6/8 



A REQUEST FOR AN EXTERNAL APPLICATION A 
RECEIVED IN PORTAL CORE FROM END USER U1 



200 



PORTAL SESSION MANAGING MEANS DETECTS THAT 
THERE IS NO SESSION FOR U1 RELATING TO APPL. A 



I 



PORTAL SESSION CREATED FOR END USER U1 AND 
EXTE RNAL APPL. A WITH PO R TAL SESSION-ID . 

I 



201 



202 



RE QUEST FORWARDED TO APPLICATION A 

i 



203 



APPL. A DETECTS THAT THERE IS NO 
SESSION FOR U1 



204 



PROPRIETARY EXTERNAL SESSION CREATED FOR U1 
AND METAINFO TAG WITH EXTERNAL SESSION-ID. 



20S 



APPL. A GENERATES APPL. DATA IN XML. SENDS 
APPL. DATA WITH METAINFO TAG TO PORTAL 



206 



PORTAL SESSION UNIFIER MAPS EXTERNAL 
SESSION-ID. ONTO PORTAL SESSION-ID- FOR U1 



PORTAL SESSION MANAGING MEANS STORES 
METAINFO DATA IN PORTAL SESSION FOR U1 



207 



208 



PORTAL RENDERS APPL. DATA AND SENDS IT TO 
END USER U1 USING ONLY PORTAL SESSION-ID. 



209 



Fig. 5 



WO 02/059787 



PCT/SE02/00113 



7/8 



SUBSEQUENT REQUEST FOR APPL. 
RECEIVED IN PORTAL FROM U1 



PORTAL SESSION MANAGING MEANS LOOKS UP PORTAL 
SESSION FOR U1 USING PORTAL SESSION ID. 



SESSION MANAGING MEANS DETECTS META- 
INFO IN PORTAL SESSION FOR U1 



REQUEST INCLUDING METAINFO 
SENT TO APPL. A 



APPL. A USES EXTERNAL SESSION ID. AS 
INCLUDED IN METAINFO TO LOOK UP 
EXTERNAL SESSION FOR U1 



APPL. A CREATES (XML)-DATA, INTRODUCES 

METAINFO TAG INTO XML-DATA AND SENDS 

XML-DATA WITH METAINFO TAG T O PORT AL 
1 



i STEPS 207. 208. 209 OF FIG 5.i 



Fig. 6 



WO 02/059787 



PCT/SE02/00113 



8/8 




or 



CD 
OO 
OO 
LU 

oo 

2 CD 

CD bj 
OO ^ 
OO 

u_i <C 
OO CD 



Q_ Q_ 



o 

CL 



or > 

LU OC 
OO LU 
=3 CO 





CD 

cr z 

z z o 

got/) 
oo oo J-fj 

OO L/O 

lu lu k_? 
<a: <C < 

Q_ LlJ 
CD CD CD 



oo 
oo 

LU 

oo 

CD 



1 J 

<c 

CD 
LU 

or 
a 

oo 

CL 



LU CL 
OO LU 

ZD or: 



INTERNATIONAL SEARCH REPORT 



International application No. 

PCT/SE 02/00113 



A. CLASSIFICATION OF SUBJECT MATTER 



IPC7: G06F 17/30, H04L 29/06 . 

According to International Patent Classification (IPC) or to both national classification and IPC 



B. FIELDS SEARCHED 



Minimum documentation searched (classification system followed by classification symbols) 

IPC7: G06F, H04L 



Documentation searched other than minimum documentation to the extent that such documents are included in the fields searched 

SE,DK,FI,N0 classes as above 



Electronic data base consulted during the international search (name of data base and, where practicable, search terms used) 



EPO-INTERNAU WPI DATA 



C. DOCUMENTS CONSIDhRF.D TO BE RELEVANT 



Category' 



Citation of document, with indication, where appropriate, of the relevant passages 



Relevant to claim No. 



W0 0065773 A2 (FIRSTPERS0M.COM), 2 November 2000 
(02.11.00), page 1, line 31 - page 2, line 36, 
claim 1, abstract 



US 6012098 A (BAYEH,E.N. ET AL.), 4 January 2000 

(04.01.00), column 3, line 30 - column 5, line 5, 
figure 4, claim 1, abstract 



W0 0039666 Al (SPYGLASS, INC), 6 July 2000 

(06.07.00), page 8, line 1 - page 10, line 5, 
abstract 



1-27 



1-27 



1-27 



| yj Further documents are listed in the continuation of Box C. | xl See patent family annex. 



• Special categories of cited document* 

"A" document defining the genera! state of the an wruch is not considered 

to be of particular relevance 
"E" earlier application or patent but publics on or after the international 

filing date 

"L* document which may throw doubts on pnooty claim(s) or which is 
cited to establish the publication dale of another a tab an or other 
special reason (as specified) 

"O" document referring to an oral disclosure, use, exhibition or other 
means 

'P* document published prior to the internals oral filing date but later than 
the priority date claimed 



*T* later document published after the international filing date or priority 
date and not in conOict with the application but cited to understand 
the principle or theory underlying the invention 

"X* document of particular relevance: the claimed invention cannot be 
considered novel or cannot be considered to involve an inventive 
step when the document is taken alone 

•V document of particular relevance: the claimed invention cannot be 
considered to involve an inventive step when the document is 
combined with one or more other such documents, such combination 
being obvious to a person skilled in the art 

document member of the same patent family 



Date of the actual completion of the iniernauonal search 



23 April 2002 



Date of mailing of the international search report 



3 0 -04- 2002 



Name and mailing address of the ISA/ 
Swedish Patent Office 
Box 5055. S-102 42 STOCKHOLM 
Facsimile No. + 46 8 666 02 86 



Authorized officer 

Par Heimdal/LR 

Telephone No. + 46 8 782 25 00 



Form PCT/iSA/210 (second sheet) (July 1998) 



2 



International application No. 
INTERNATIONAL SEARCH REPORT PCT/SE 02/00113 


C (Continuation). DOCUMENTS CONSIDERED TO BE RELEVANT 


Category* 


Citation of document, with indication, where appropriate, of the relevant passages 


Relevant to claim No. 


P,A 


WO 0144936 A2 (MICROSOFT CORP), 21 June 2001 
(21.06.01) 


1-27 



Form PCT/ISA/210 (continuation of second sheet) (July 1998) 



INTERNATIONAL SEARCH REPORT 

Information on patent family members 



28/01/02 



International application No. 
PCT/SE 02/00113 



Patent document 
cited in search report 


Publication 
date 


Patent family 
member(s) 


P u SI icAtj n n 

date 


WO 0065773 


A2 


02/11/00 


AU 


4495400 A 


10/11/00 


UUlfcUJO 


A 




04/01/00 


NONE 






WO 0039666 


Al 


06/07/00 


DE 


19962192 A 


06/07/00 








FI 


992746 A 


9Q /AC /ftft 

£o/ uo/ uu 










GB 


2347329 A 


30/08/00 










GB 


9930699 D 


00/00/00 










JP 


2000194612 A 


14/07/00 










SE 


9904687 A 


29/06/00 


W0 0144936 


A2 


21/06/01 


AU 


1820801 A 


25/06/01 



Form PCT/ISA/210 (patent family annex) (July 1998) 



